Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add "fbask_jan16_sticky" realization to livestock module #678

Conversation

DavidhoPIK
Copy link
Contributor

@DavidhoPIK DavidhoPIK commented May 22, 2024

🐦 Description of this PR 🐦

This PR adds the fbask_jan16_sticky realization to the livestock module. It is a "sticky" version of the fbask_jan16 realization, that uses the (simplified) methodology of the sticky_feb18 factor cost realization for it's factor costs calculation.

The documentation describes the difference to fbask_jan16 as follows:

In this realization the capital share of livestock production cost does not have 
to be paid every timestep, but is fulfilled by having a corresponding capital stock,
which mostly persists across timesteps. (See `s70_depreciation_rate`)
This means that the production becomes cheaper in regions with
higher capital shares and existing corresponding capital stocks,
which makes the livestock production "stick" to some degree to existing levels. 
Another effect is that production increases are more likely to occur in regions
of more capital intensive livestock systems with already established stocks.

The realization is based on the `sticky_feb18` factor cost realization, but
also differs from it in some ways. At the creation time the main differences were: 
1. capital stocks are on the regional level not on cluster level
2. no differentiation of mobile and immobile capital - all capital stocks are immobile

🔧 Checklist for PR creator 🔧

  • Label pull request from the label list.

    • Low risk: Simple bugfixes (missing files, updated documentation, typos) or changes in start or output scripts
    • Medium risk: Uncritical changes in the model core (e.g. moderate modifications in non-default realizations)
    • High risk: Critical changes in model core or default settings (e.g. changing a model default or adjusting a core mechanic in the model)
  • Self-review own code

    • No hard coded numbers and cluster/country/region names.
    • The new code doesn't contain declared but unused parameters or variables.
    • magpie4 R library has been updated accordingly and backwards compatible where necessary.
    • scenario_config.csv has been updated accordingly (important if default.cfg has been updated)
  • Document changes

    • Add changes to CHANGELOG.md
    • Where relevant, put In-code documentation comments
    • Properly address updates in interfaces in the module documentations
    • run goxygen::goxygen() and verify the modified code is properly documented
  • Perform test runs

    • Low risk:
      • Run a compilation check via Rscript start.R --> "compilation check"
    • Medium risk:
      • Run test runs via Rscript start.R --> "test runs"
      • Check logs for errors/warnings
    • High risk:
      • Run test runs via Rscript start.R --> "test runs"
      • Check logs for errors/warnings
      • Default run from the PR target branch for comparison
      • Provide relevant comparison plots (land-use, emissions, food prices, land-use intensity,...)

📉 Performance changes 📈

  • Current develop branch default (gams execution): 20.0 mins
  • This PR's default : 19.5mins

🚨 Checklist for reviewer 🚨

  • PR is labeled correctly
  • Code changes look reasonable
    • No hard coded numbers and cluster/country/region names.
    • No unnecessary increase in module interfaces
    • model behavior/performance is satisfactory.
  • Changes are properly documented
    • CHANGELOG is updated correctly
    • Updates in interfaces have been properly addressed in the module documentations
    • In-code documentation looks appropriate
  • content review done (at least 1)
  • RSE review done (at least 1)

@DavidhoPIK DavidhoPIK changed the title add "fbask_jan16_sticky" realization of livestock module add "fbask_jan16_sticky" realization to livestock module May 22, 2024
@DavidhoPIK DavidhoPIK added the enhancement New feature or request label May 23, 2024
@DavidhoPIK
Copy link
Contributor Author

DavidhoPIK commented May 27, 2024

The main intended effect of the realization is that it provides more stability to the livestock production, in scenarios of more liberal trade.

The largest differences are visible when using superregions (with completly free trade within each superregion), but the effect can also be seen to some extend with normal h12 magpie. (unfortunately the h16s5 preprocessing using a superregion depends on the newest mrcommons version which doesn't run with the develop at the moment)

Here are plots of a default h12 run (without landconversion costs and yield calibration from a calibration run) with and without the new realization. In contrast to the default I used cfg$gms$c21_trade_liberalization <- "l908080r807070" to better show the stabilizing effect under more liberal trade.

See /home/davidho/MAgPIEG/magpieEU/develop_add_sticky_livestock_implementation/output for the complete results and settings.

From all the shiny results of the relevant livestock variables I always only show those variables and regions where significant differences do occur:

image

image

image

image

image

image

image

image

@DavidhoPIK
Copy link
Contributor Author

DavidhoPIK commented May 27, 2024

Here are some more plots of "standard" variables for completeness:
image

image

image

There is also a peculiar effect on rice production, which is hard for me to interpret:
image

@DavidhoPIK
Copy link
Contributor Author

The only warnings/errors from the GAMS model run I got where:

**** ERRORS/WARNINGS IN VARIABLE vm_land(MEA_93,primforest)
     1 error(s): Variable considered fixed at the initial value projected on the bounds.
**** ERRORS/WARNINGS IN VARIABLE vm_land(EUR_43,primforest)
     1 error(s): Variable considered fixed at the initial value projected on the bounds.

I think these errors are unrelated to the new realization. They also do not stop the execution of the GAMS code.

@DavidhoPIK DavidhoPIK requested review from tscheypidi and emolinab May 27, 2024 15:44
@DavidhoPIK DavidhoPIK marked this pull request as ready for review May 27, 2024 17:46
Copy link
Member

@tscheypidi tscheypidi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me. Found just one typo.

modules/70_livestock/fbask_jan16_sticky/realization.gms Outdated Show resolved Hide resolved
@DavidhoPIK
Copy link
Contributor Author

DavidhoPIK commented May 28, 2024

I decided to do another evaluation of the new realization with more more extreme settings, to show in which direction the effects go. The following plots are with the settings:

cfg$gms$c21_trade_liberalization <- "free2000"

cfg$gms$s70_multiplicator_capital_need <- 3
cfg$gms$s70_depreciation_rate <- 0.02

So we have a higher capital need, a lower depreciation of stocks and a very free trade. Of course these settings are unrealistic but they serve to show how the main effect of using the realization: It then takes time to build up capital stocks and production is not so easily shifted away from regions when capital stocks are already build up.

image

image

image

image

image

image

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there a s70_multiplicator_capital_need?

Copy link
Contributor Author

@DavidhoPIK DavidhoPIK May 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the s70_multiplicator_capital_need multiplikator to reflect uncertainty that we may have in the capital need (LN75 of preloop).

So the default capital need is such that multiplied with the sum of interest rate and depreciation rate it equals the capital factor requirements. This means it strongly depends on the depreciation rate which is also configurable and a global estimate.

In general my guess would be that it is not so easy to estimate the capital need from the VoP, capital share, interest and depreciation rates. (Correct me if i'm wrong!)

Copy link
Contributor

@emolinab emolinab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good and very cool to me! I am missing the difference in run time with the implementation activated, and it is not so clear why a s70_multiplicator_capital_need is needed.

@DavidhoPIK
Copy link
Contributor Author

DavidhoPIK commented May 29, 2024

Thank you very much for the review and comment! There was no significant difference in the runtime 19,5 min with the realization 20 min without (only checked for the first of the two test runs i did).

@DavidhoPIK DavidhoPIK merged commit 1d06d91 into magpiemodel:develop Jun 21, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Medium risk
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants